Search Results: "cmc"

3 November 2008

Enrico Zini: rc-buggy packages sorted by popularity

rc-buggy packages sorted by popularity After doing a round of tag reviews so that we release lenny with the latest tag contributions, I still had a bit of spare time. Since people are urging to fix the last bugs I thought I could contribute a list of RC-buggy packages sorted by popularity:

#!/usr/bin/python
import urllib2
import sys, re #, gzip
PKGRE = re.compile(r'<strong>Package: </strong><a href="[^"]+" name="([^"]+)">')
POPCONRE = re.compile(r'^(\d+)\s+(\S+)')
PKGMAPRE = re.compile(r'^([^(]+)\(([^)]+)')
COMMASPLIT = re.compile(r'\s*,\s*')
# Allow to download other package views
if len(sys.argv) > 1:
    url = sys.argv[1]
else:
    url = "http://bts.turmzimmer.net/details.php"
def read_packages(url):
    "Download the list of rc-buggy packages"
    fd = urllib2.urlopen(url)
    for line in fd:
        mo = PKGRE.search(line)
        if mo:
            yield mo.group(1)
# FIXME: this is a deprecated data source, but at the moment it is just what
#        is needed
def read_bintosrc(url = "http://qa.debian.org/data/ddpo/results/ddpo_packages"):
    "Download the binary to source package map"
    fd = urllib2.urlopen(url)
    for line in fd:
        mo = PKGMAPRE.search(line)
        if mo:
            src = mo.group(1)
            bin = COMMASPLIT.split(mo.group(2))
            for p in bin:   
                yield p, src
def read_popcon(url = "http://popcon.debian.org/by_inst"):
    "Download popcon information"
    fd = urllib2.urlopen(url)
    # It doesn't work on urllib2 objects because it wants tell()
    #fd = gzip.GzipFile(fileobj=fd, filename=url, mode="rb")
    for line in fd:
        mo = POPCONRE.match(line)
        if mo:
            yield mo.group(2), int(mo.group(1))
print "Reading mapping of binary packages to source packages..."
bin2src = dict(read_bintosrc())
print "Reading popcon scores..."
# We actually want the score of source packages, and for it we use the score of
# its binary package with the highest score
scores = dict()
for pkg, score in read_popcon():
    pkg = bin2src.get(pkg, pkg)
    if pkg not in scores:
        scores[pkg] = score
#scores = dict(read_popcon("http://popcon.debian.org/by_inst.gz"))
print "Reading list of rc-buggy packages..."
# The bug page has a mix of source and binary packages: convert all to source
# packages
packages = sorted(read_packages(url), key=lambda x:scores.get(bin2src.get(x,x), 0))
for p in packages:
    print scores.get(bin2src.get(p,p), 0), p

This can be run on people.debian.org as ~enrico/popzimmer (0 is the rank of packages that for some reason cannot be mapped to any rank):

$ ~enrico/popzimmer 
Reading mapping of binary packages to source packages...
Reading popcon scores...
Reading list of rc-buggy packages...
0 roxen-fonts-iso8859-2
2 dpkg
11 pam
61 glibc
61 libc6
123 initramfs-tools
149 bind9
150 grub
180 portmap
213 nfs-common
279 libgl1-mesa-dri
298 libsnmp-base
298 snmpd
309 avahi
397 mysql-dfsg-5.0
408 xserver-xorg-input-wacom
409 xserver-xorg-video-vesa
428 docbook-xml
499 openoffice.org-core
567 xine-lib
600 evolution-data-server
669 eog
671 xserver-xorg-video-intel
691 epiphany-browser
691 epiphany-gecko
695 kdelibs4c2a
698 uswsusp
754 guile-1.6
959 gpm
964 cups
990 kdebase
1002 ghostscript
1069 giflib
1076 xulrunner-1.9
1177 libapache2-mod-perl2
1217 vlc-nox
1229 kernel-package
1311 kdeutils-dev
1520 libparted1.8-10
1767 wireshark
1785 selinux-policy-default
1908 dia
1943 htop
1983 boost
2140 cantlr
2145 transmission
2159 emacs22
2312 swfdec-mozilla
2449 eclipse
2449 libswt3.2-gtk-java
2728 lilo
2898 libnss-ldap
3013 java-access-bridge
3051 blender
3099 libtemplate-perl
3499 fglrx-atieventsd
3602 virtualbox-ose
3619 jfsutils
3806 anjuta
3962 kbuild
4076 libgnustep-gui0.14
4222 libwebkit-1.0-1
4332 rosegarden
4412 matplotlib
4412 python-matplotlib
4950 mail-notification-evolution
5195 nut-cgi
5273 sbcl
5538 ruby1.9
5679 kmymoney2
6076 websvn
6147 miro
6264 gnat-4.1
6431 gallery2
6478 gnome-chess
6512 joystick
6862 istanbul
6937 wordpress
7476 luatex
7635 csound
7635 python-csoundac
8257 libpam-mount
8471 wmcpuload
8631 nbsmtp
8642 oxine
8774 axiom
8949 libengine-pkcs11-openssl
9052 clamav-getfiles
9221 open-iscsi
9262 ptex-bin
9701 egroupware-core
10012 debian-cd
10127 libjogl-java
10453 libjson-xs-perl
10698 gcjwebplugin
10736 request-tracker3.6
11294 python-extclass
11518 rkward
11600 alevt
12929 otrs2
13205 bindgraph
13956 icecc-monitor
14223 netmaze
14505 cdebconf
14526 mumble
14687 fnonlinear
14724 recite
14789 jbidwatcher
15766 libnss-ldapd
15812 glpi
15905 lustre-source
15982 win32-loader
16232 ampache
17168 libghc6-missingh-dev
17311 acl2
17830 apertium
18462 emacspeak
18469 glassfish
19257 isight-firmware-tools
19719 libnagios-object-perl
20144 libwx-perl
20465 dns2tcp
21614 python-kinterbasdb-dbg
21690 hf
21902 libcobra-java
22365 tomcat6
22573 libphp-snoopy
23501 coco-java
23926 boxbackup-server
24009 libghc6-wash-dev
26323 libdesktop-notify-perl
26439 opendb
28426 adolc
28795 xorp
29986 libgdata-java
31262 libjboss-serialization-java
31472 pixelpost
31658 cournol
32939 mediamate
34365 gforge-plugin-scmcvs
34659 libgearman-client-async-perl
42233 libhamcrest-java
48076 mahara
55303 mxallowd
85881 roxen-fonts-iso8859-1

So, if you don't know from what package to start fixing bugs, "Begin at the beginning,", the King said, very gravely, "and go on till you come to the end: then stop."

24 October 2008

John Goerzen: The End of an Era

I bought my first Apple hardware a number of years ago -- a 400MHz titanium Powerbook. The thing came with Mac OS X preloaded, but it was so slow that it was unusable. I put Debian on it, and was mostly happy with it -- until the titanium case started coming apart. Oh, and the small detail that the built-in wifi reception was so poor that I had to use a PCMCIA card to get a signal in some parts of my house.

But ever since then, we've always had some piece of Apple hardware in active use in our house.

About 7 years ago, my main workstation was a rapidly-aging 600MHz Alpha with -- gasp -- PCI video. It was OK for programming but really awfully slow at anything graphical. I was wanting to get into video editing, and we bought an 800 MHz iMac. The kind with the inverted-bowl base. A nice machine at the time. This was going to be my main workstation.

When it arrived at home, I unpacked it. Terah walked in and said, "Wow, my new computer is cute!" So it became *her* computer, and has been ever since.

It's rather old and is showing its age. Its wifi card died a couple of years ago. The 800MHz CPU is slow with today's websites.

So yesterday, we clicked on the apple and shutdown for the last time. It left her desk, replaced with a Linux desktop with a 20" 1600x1200 LCD (replacing the 15" 1024x768). I had assembled this Linux desktop out of spare parts in our basement, with a 4-year-old Athlon XP CPU. It's still faster than her Core 2 Duo work laptop running Vista, but that's another story.

I put Debian lenny on it. And I've got to say -- wow -- the utility of Debian as a desktop OS for the non-geeky has taken an incredible turn for the better in the last few years. Terah was fine with switching to Linux. I set it up for her -- Firefox for web, Thunderbird for mail, J-Pilot for syncing to her Palm, OpenOffice, gajim, etc.

Her concerns were: having Thunderbird make a nice "whoosh" sound when it successfully finished transmitting an email, having desktop gadgets (I installed screenlets, which I think she likes a lot), and.... I don't think I remember any others.

So now we both run Linux on our desktops.

Oh, and on her laptop, I poked around in the Vista control panels (I must have "authorized it to display this panel" a dozen times, stupid thing), and eventually found a box where I could optimize for visual effects or optimize for performance. I hit optimize for performance, and it transformed its interface into approximately Windows 2000 after a couple of seconds. I think that change made it a lot faster. It's now about as fast as the 25%-as-fast Linux box. I guess that's good for Vista.

28 September 2008

Jonathan McDowell: Which data contract?

I bought an EEE 901. More on that later.

For the past few weeks I've been trying to work out which "mobile broadband" provider to go with for my daily commute. It's a train journey from the north coast of Northern Ireland to Belfast and goes through some sparsely populated areas, so I wasn't expecting to get anything that would provide 3G all the way. However I do want a provider that can do their best to keep a session up for the journey, handing over between 2G + 3G as necessary. Coverage maps/checkers aren't too bad if you just want to check a static point, but really even then it's better to actually try the provider in the location yourself. So, armed with a bluetooth GPS (Bl eNEXT BN-909GR), an Option GT 3G Quad PCMCIA card and my laptop I set about measuring signal strength along my train journey for each of the 5 providers available. I also made sure to actually try a session with them for at least one journey, because signal strength is not everything.

I wrote some Perl using Net::GPSD and Device::Gsm to query my current location, signal strength, 2G/3G status and network every 10 seconds. I did this for 3 train journeys (except for O2) and then also produced an "optimistic" file of all the data points combined for that provider.

A second piece of Perl took this data and drew the maps you see below. The graph on the right for each provider is all data points. Red means 2G, blue means 3G, green means "Limited Service" (ie it could see a signal, but not one it was allowed to connect to). White means that we had a GPS location and no signal at all. Click on the maps for bigger versions. You can see the route on OpenStreetMap - my graphs are a little squished horizontally, but the journey is from Castlerock (top left on the coast near Coleraine) to Belfast (bottom right).

At first glance 3 look to be the best bet. Lots of blue, a reasonably priced data plan. Except they can't hold up a session to save themselves. Not only does a 2G/3G handover almost always seem to result in a drop, but I had periods of failing to get a 2G session up at all and had some random drops while in 3G coverage as well. So strike them off.

O2 and T-Mobile don't manage any 3G outside Belfast (that's the bottom right corner btw). I found that a few periods of 3G along the journey helped a lot; it meant I could do a quick mail sync rather than the long drawn out affair it was on a 2G connection. They can both handle handover between 2G/3G and keep a session up for most of the journey, but the lack of speed counts them out.

Vodafone managed the worst reception, which is disappointing. I found them quite good when I lived in England (my datacard is from a Vodafone Pay as You Use data contract). I did find sessions being dropped during the no signal regions, so they just don't seem to be a good bet.

Which leaves Orange. I've had issues with Orange and data in the past (pre 2004 IIRC) but in testing they were able to keep a session up between Belfast and Castlerock, handling 2G/3G handover fine. Coverage was reasonably good and they manage 3G at several points along the journey (the blue points roughly correspond to Coleraine, Ballymena, Antrim and Belfast). I understand Orange have some EDGE capability, but my card doesn't do EDGE so I've no idea if that'll be an extra gain or not. I had a few issues with getting dud DNS servers but this happened with the other providers too so I was beginning to suspect the datacard of playing up. Manually setting known good servers in resolv.conf worked fine.

So, before I go and sign up to an 18 month Orange contract, what have I forgotten?

18 August 2008

Russell Coker: SE Linux Policy Packaging for a Distribution

Caleb Case (Ubuntu contributer and Tresys employee) has written about the benefits of using separate packages for SE Linux policy modules [1]. Firstly I think it’s useful to consider some other large packages that could be split into multiple packages. The first example that springs to mind is coreutils which used to be textutils, shellutils, and fileutils. Each of those packages contained many programs and could conceivably have been split. Some of the utilities in that package are replaced for most use, for example no-one uses the cksum utility, generally md5sum and sha1sum (which are in the same package) are used instead. Also the pinky command probably isn’t even known by most users who use finger instead (apart from newer Unix users who don’t even know what finger is). So in spite of the potential benefit of splitting the package (or maintaining the previous split) it was decided that it would be easier for everyone to have a single package. The merge of the three packages was performed upstream, but there was nothing preventing the Debian package maintainer from splitting the package - apart from the inconvenience to everyone. The coreutils package in Etch takes 10M of disk space when installed, as it’s almost impossible to buy a new hard drive smaller than 80G that doesn’t seem to be a problem for most users. The second example is the X server which has separate packages for each video card. One thing to keep in mind about the X server is that the video drivers don’t change often. While it is quite possible to remove a hard drive from one machine and install it in another, or duplicate a hard drive to save the effort of a re-install (I have done both many times) they are not common operations in the life of a system. Of course when you do require such an update you need to first install the correct package (out of about 60 choices), which can be a challenge. I suspect that most Debian systems have all the video driver packages installed (along with drivers for wacom tablets and other hardware devices that might be used) as that appears to be the default. So it seems likely that a significant portion of the users have all the packages installed and therefore get no benefit from the split package. Now let’s consider the disk space use of the selinux-policy-default package - it’s 24M when installed. Of that 4.9M is in the base.pp file (the core part of the policy which is required), then there’s 848K for the X server (which is going to be loaded on all Debian systems that have X clients installed - due to an issue with /tmp/.ICE-unix labelling [2]). Then there’s 784K for the Postfix policy (which is larger than it needs to be - I’ve been planning to fix this for the past four years or so) and 696K for the SSH policy (used by almost everyone). The next largest is 592K for the Unconfined policy, the number of people who choose not to use this will be small, and as it’s enabled by default it seems impractical to provide a way of removing it. One possibility for splitting the policy is to create a separate package of modules used for the less common daemons and services, if modules for INN, Cyrus, distcc, ipsec, kerberos, ktalk, nis, PCMCIA, pcscd, RADIUS, rshd, SASL, and UUCP were in a separate package then that would reduce the installed size of the main package by 1.9M while providing no change in functionality to the majority of users. One thing to keep in mind is that each package at a minimum will have a changelog and a copyright file (residing in a separate directory under /usr/share/doc) and three files as part of the dpkg data store, each of which takes up at least one allocation unit on disk (usually 4K). So adding one extra package will add at least 24K of disk space to every system that installs it (or 32K if the package has postinst and postrm scripts). This is actually a highly optimal case, the current policy packages (selinux-policy-default and selinux-policy-mls) each take 72K of disk space for their doc directory. One of my SE Linux server sytems (randomly selected) has 23 policy modules installed, if they were in separate packages there would be a minimum of 552K of disk space used by packaging, 736K if there were postinst and postrm scripts, and as much as 2M if the doc directory for each package was similar to the current doc directories). As the system in question needs 5796K of policy modules, the 2M of overhead would make it approach 8M of disk space. So it would only be a saving of 16M over the current situation. While saving that amount of disk space is a good thing, I think that when balanced against the usability issues it’s not worth-while. Currently the SE Linux policy packages will determine what applications are installed and automatically load policy packages to match. I don’t believe that it’s possible to have a package post-inst script install other packages (and if it is possible I don’t think it’s desirable). Therefore to have separate packages would make a significant difference to the ease of use, it seems that the best way to manage it would be to have the core policy package include a script to install the other packages. Finally there’s the issue of when you recognise the need for a policy module. It’s not uncommon for me to do some work for a client while on a train, bus, or plane journey. I will grab packages needed to simulate a configuration that the client desires and then work out how to get it going correctly while on the journey. While it would not be a problem for me (I always have the SE Linux policy source and all packages on hand) I expect that many people who have similar needs might find themself a long way from net access without the policy package that they need to do their work. Sure such people could do their work in permissive mode, but that would encourage them to deploy in permissive mode too and thus defeat the goals of the SE Linux project (in terms of having wide-spread adoption). My next post on this topic will cover the issue of custom policy. Updated to note that Caleb is a contributor to Ubuntu not a developer.

[1] http://www.calebcase.com/node/2

[2] http://marc.info/?l=selinux&m=121789588709977&w=2

14 August 2008

Uwe Hermann: Physical memory attacks via Firewire/DMA - Part 1: Overview and Mitigation

This is part 1 of a series on articles about the Firewire security issues mentioned below. For many years now, attacks via Firewire / i.LINK / IEEE 1394 have been a known security issue. Basically, if you gain physical access to a PC or laptop which has Firewire ports (or PCMCIA/Cardbus/ExpressCard, more on that later) you can

read arbitrary RAM contents from the victim's system,
overwrite arbitrary RAM contents with whatever you want,
and perform many, many severe attacks based on the two issues above. Examples include grabbing a full RAM dump via Firewire (takes only a few minutes), grabbing ssh-agent keys, grabbing screen contents, modifying screen contents, bypassing login/password screens, and many, many more...

All of this is done by exploiting a "feature" of the Firewire spec (OHCI-1394) (PDF), namely that it allows read/write access to physical memory (via DMA) for external Firewire devices. Worse, as this is DMA, the CPU/OS will not even know what's going on. Even worse, this works regardless of whether you have locked your screen with a password-protected screensaver, or xlock, or vlock, or whatever. As long as the system is running, you're vulnerable. In this article, I intend to give a fairly complete overview of the available papers published on this issue, tools for testing the attacks, as well as mitigation techniques for various OSes. If I'm missing some important papers or tools, please post a comment! Papers, Attacks, and Tools Over the years a number of presentations and papers have been released with information about these Firewire issues. Maximilian Dornseif et. al. The first publication that I know of was done by Maximilian Dornseif, Michael Becher, and Christian Klein. They gave a number of talks on various security conferences on this topic:

They also released a number of tools, Firewire libraries for Mac OS X and Linux, as well as small demo scripts which use those libs:

pyfw-20041111.tar.gz: Mac OS X Firewire bindings for Python, various demos
http://c0re.23.nu/c0de/pyfw/: Other versions of the above code
pyfw_linux.tar.gz: Linux Firewire bindings for Python (can be used with above demo code on Linux)
ipod-linux-pyfw.tar.bz2: Instructions (+ disk image) on how to turn your iPod into a Firewire attack tool

Adam Boileau In 2006 Adam Boileau (a.k.a. Metlstorm) gave a talk called Hit by a Bus: Physical Access Attacks with Firewire (PDF) at Ruxcon 2006. In 2008 he then released a set of tools:

pythonraw1394-1.0.tar.gz: Python bindings for libraw1394 (Linux). Tools: businfo, romtool, 1394memimage
winlockpwn: Python script which can circumvent a locked Windows XP screen (an arbitrary password will log you in)
bioskbsnarf: Grabs/shows the BIOS keyboard buffer via Firewire (which often contains your BIOS password)

Peter Panholzer As of early 2008 Peter Panholzer from sec-consult.com published a two-page whitepaper which says they were able to run a winlockpwn-like attack on Windows Vista via Firewire. There's not much information in the PDF unfortunately, and no tools were released, as far as I know.

David R. Piegdon The most recent toolset and papers I know of are from David R. Piegdon (a.k.a. IosTrace), who gave a number of talks in 2007/2008 about the issue, and also released a toolset called SEAT1394.

2007: OpenChaos: hacking in physically addressable memory (no extra slides)
Easterhegg 2008: FireWire Hacking: paper (PDF), slides (PDF)
More papers here...
http://0null.net/software/SEAT1394/: tools and libraries for pyhsical memory access via Firewire/DMA: 1394csrtool, liblinear, libphysical, debug-sshkey, dump-memory, remote-ps, show-stack, snarf-sshkey, test-all-pagedirs, dmashell, ...

I'll go into much more detail on how the tools are used and what they can do in another follow-up article. Mitigation There are ways to eliminate or at least mitigate these attack vectors. The simplest and most secure way is to not have any Firewire ports installed (don't put Firewire PCI/PCIe cards in your PC, don't use Firewire PCMCIA/Cardbus/ExpressCard cards). Now, if you have a laptop with built-in Firewire ports, you have a problem, of course. In that case you could still physically destroy the port (by opening the laptop and cutting/desoldering stuff, or by putting glue/epoxy in the port in order to prevent any Firewire cables being attached). These are slightly drastic (but effective!) measures. Note: Even if you don't have any Firewire ports, you're not automatically safe and secure. If your laptop has a PCMCIA/Cardbus/ExpressCard slot, an attacker can simply insert a PCMCIA Firewire card (for instance) in that slot. Chances are, that your OS will automatically load the driver for that card and also the Firewire drivers you'll need if you want to use the card for attaching Firewire devices. Game over. Your "secure" laptop is now vulnerable... If you cannot (or don't want to) remove/destroy/disable your Firewire ports, the next best thing is to ensure that nobody except yourself ever gets physical access to your PC/laptop. This is hard to do for a PC, and almost impossible for a laptop, mind you. Finally, there are some software measures you can use to prevent at least physical DMA access for Firewire devices: Mitigation: Linux Pretty much every Linux system with the "old" Firewire drivers loaded (kernel module ohci1394 et. al.) is vulnerable to these issues. Newer kernels now also ship with a new Firewire stack called "juju" (kernel module firewire_ohci et. al.) which may or may not have the same issues (not fully tested by me so far, will report back later). Per default, all recent kernels, e.g. 2.6.26, are vulnerable, but see below. Under Linux, simply using a kernel which doesn't have any Firewire support (neither built-in, nor as a module) is the most secure option. If you must have Firewire support you can load the ohci1394 module with the phys_dma=0 parameter to at least disable physical DMA support:

  $ modprobe ohci1394 phys_dma=0

I have personally tested this on some boxes and I can confirm that it renders the currently published tools useless. As for the new "juju" Firewire stack, I'm not so sure. A few quick tests showed that the currently available tools don't work with the new stack, but you shouldn't feel too secure! AFAIK the new stack does support (or will support soon) physical DMA for Firewire, so it's probably just a matter of adapting the tools a bit (I'll do some testing/research on this later, as time permits). Mitigation: Mac OS On Mac OS you might also be able to completely remove Firewire support from the kernel (but I don't know if/how that can be done, not sure if you can easily recompile Mac OS kernels, and/or if you even have buildable source code and toolchains for that). However, you can at least remove the Firewire support in the default Mac OS installation by unloading AppleFWOHCI.kext:

  $ sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext

Thanks to a Daniel Reutter for letting me abuse his MacBook via Firewire and for finding the above kextunload command line. We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore. The tests were done on a Mac OS X Tiger (I think) with all recent security updates applied. Please leave a comment if you can test other versions of Mac OS X... Mitigation: Windows As for Windows, well, I guess you're screwed. While Windows XP does implement sort of "protection" in that it only allows physical DMA access via Firewire to devices which "deserve it", e.g. iPods (or any other Firewire mass storage device, I guess) this can be easily defeated by having your attack PC/laptop pretend to be an iPod (see the romtool Python script by Adam Boileau). The only remaining option I know of (short of removing/destroying Firewire ports or preventing physical access alltogether) is to disable the Firewire ports/drivers in the device manager (untested by me so far). If you do that, remember to also disable all PCMCIA/Cardbus/ExpressCard controllers, of course (see above). So far I've tested Windows XP SP2/SP3 successfully with Adam Boileau's tools. I haven't yet been able to test Windows 95/98/Vista, if you can verify one of them, please leave a comment. Mitigation: OpenBSD/FreeBSD/NetBSD/OpenSolaris/... On OpenBSD you're likely not vulnerable as OpenBSD doesn't have any Firewire drivers at all, as far as I know ;-) As for FreeBSD, NetBSD, OpenSolaris, and other OSes I don't have any information. I might be able to test one or two of them in the nearer future, but please leave a comment if you have some information about whether they are vulnerable and/or how you can secure your system... Conclusion That's it for now. I hope you now have a good overview of these issues and how to protect. I can only urge you to take this problem seriously! Three or four minutes of leaving your laptop unattended are fully sufficient for an attacker to get a full forensic image of all your RAM contents for later analysis. This is at least as critical as the Cold Boot attacks, if not worse. I will follow-up with more articles about some more interesting details on these Firewire issues, how to use the above tools, and I'll report on some of the stuff I was able to find in RAM dumps gathered via Firewire...

23 March 2008

Neil Williams: Porting a C package from libgnomevfs to GIO and GVfs.

(Note: this is a long post)
Package: deb-gview
Use of GnomeVFS: "Individual package files or packages referenced in a changes file can be viewed from local or remote filesystems using GNOME VFS."
Main changes: src/dvarchive.c but also src/main.c.
Port Status: Complete and tested.
Prerequisites
Do not run any code before completing this step
You must ensure that gvfs, gvfs-bin and gvfs-backends are all installed and operational before running any of your modified code. Thereby hangs another tale. The application itself probably needs to depend on both gvfs and gvfs-backends. gvfs-bin provides test binaries like gvfs-info.
You need to ensure that the following command operates correctly:

$ gvfs-info http://www.google.com

display name: /

edit name: /

type: unknown

size: 0

attributes:

  standard::display-name: /

  standard::edit-name: /

  standard::content-type: text/html

  id::filesystem: type='http',uri='http://www.google.com',mount_prefix='/'

Note that this is run as the normal user, not under sudo and not as root. - that just complicates things. If you find that this works with sudo but not without, read the bug report against gvfsd.
If you get this output:

$ gvfs-info http://www.google.com

Error getting info: The specified location is not supported

read the bug report, find and kill the borked gvfsd process and ensure that gvfs-backends is installed before attempting any other gvfs* commands (including via your modified source code).
Starting

Online copy of the GIO docs. online copies of the GVfs docs. I mainly use Anjuta where both sets of the docs are available via libglib2.0-doc >= 2.16.1 and devhelp or via your localhost using dwww.

#include <gio/gio.h> to replace #include <libgnomevfs/gnome-vfs.h>.
(May sound obvious now but examples are not that frequent in the GIO docs as part of libglib2.0-0.)

The GIO docs do give some info on porting variables:
- GnomeVFSHandle * vfshandle; became GFile * ghandle; GInputStream * stream; in deb-gview
- Extra variables needed for deb-gview: GVfs * vfs; GError * result; GFile * gfile; GFileInfo * ginfo;. GError itself is not new but it can catch you out in the port because so many GIO/GVfs functions can use it and you find yourself using g_clear_error(&error) a lot or GLib will complain about trying to replace data in a GError.

Separate path and URI handling - GIO and GVfs have separate filename/path handling for paths on a local filesystem and paths on remote filesystems and the two cannot be mixed. This was a big source of bugs during the port (it may be a UTF-8 issue) and in the end I went for a gboolean flag in the context that this particular viewer was handling a file from a remote filesystem (e.g. http://localhost/incoming/deb-gview_0.2.0_amd64.changes, http://ftp.debian.org/debian/pool/main/e/emdebian-tools/emdebian-rootfs_0.9.1_all.deb or http://incoming.debian.org/foo_version.changes) and not from a local path (e.g. /opt/debian/deb-gview/deb-gview_0.2.0_amd64.changes or ../../debian/deb-gview/deb-gview_0.2.0_amd64.deb). Personally, I found g_file_is_native to be unsuitable for this purpose and as I had a "user-entered" path available, I simply use if ((g_str_has_prefix (path, "..")) (g_str_has_prefix (path, "/"))) but YMMV, depending on how you obtain the path itself.
Keep track of the type of input file when handling GFile - g_file_get_path will fail if passed a GFile that needs g_file_get_uri and vice-versa. These failures output messages to the console so they are relatively easy to track but not only will the call fail but the GFile itself is likely to get corrupted, leading to other bugs and messages to the console. g_vfs_get_file_for_path(vfs, path) and g_vfs_get_file_for_uri(vfs, path) (which obtain the GFile from GVfs in the first place) also fail if passed the wrong type of path.
In some situations, g_file_get_parse_name can be used to get a "normal" char* representation of the path to the GFile but I was only able to use this in specific circumstances and only when the path and URI handling flag was implemented.
This all complicates the port because gnome_vfs_make_uri_from_input did not have this separation issue.

Checking if a file exists - if (!g_file_query_exists (gfile, NULL)) may seem easy but unless issues with the URI and path are handled cleanly, this simple check will fail even though the file exists. The problem arises because GFile appears to mangle a URI with a path function and vice-versa. The GFile ends up with an invalid path and hence there is no valid file to check so the query fails - but without indicating that it's actually an internal error in GFile rather than a valid path that simply does not exist.

Reading files in one go - vfsresult = gnome_vfs_read_entire_file (vfstext, &changes_size, &contents); gets replaced with g_file_load_contents (cfile, NULL, &contents, &changes_size, NULL, &result); (note the order swap between the size and the buffer to use). Once read, the buffer can be handled as before. This is one of the easier changes in the port, once the above issues are all cleared up. On the other hand, GIO and GVfs do appear to handle relative paths more easily than GnomeVFS.

Checking VFS is active -

vfs = g_vfs_get_default ();

   if (g_vfs_is_active(vfs))

Reading files as a stream - result = gnome_vfs_read (vfshandle, readbuffer, skip, &bytesread); becomes bytesread = g_input_stream_read (stream, readbuffer, skip, NULL, &result);. Fairly straightforward as long as you use:
```
if (result)  

g_warning("Error: %s", result->message);

g_clear_error (&result);

 
```
(or something equivalent to get the error message to the user), every time you use &result.
vfs_uri = gnome_vfs_uri_new (gnome_vfs_make_uri_from_shell_arg (filename)); becomes filestream = g_file_read (deb->ghandle, NULL, &result); (there's that &result again).

Checking the stream remains open.

stream = (GInputStream*)filestream;

       if (g_input_stream_is_closed (stream))

       return FALSE;

Seeking inside the stream - YMMV but seek never appeared to work well for me in VFS so I had to read into a dump instead.
```
gpointer dump; 	        

        dump = g_new0(gchar, seek); 	        

        result = gnome_vfs_read (deb->vfshandle, dump, seek, &bytesread); 	 

        g_free (dump);
```
In GIO, seek is much easier: g_input_stream_skip (stream, seek, NULL, &result); - just handle that &result again.

Closing the stream - gnome_vfs_close (vfshandle); becomes g_input_stream_close (stream, NULL, &result);.

Getting information on files - if ((vfsinfo->type != GNOME_VFS_FILE_TYPE_REGULAR) (vfsinfo->size == 0)) becomes

ginfo = g_file_query_info (ghandle, G_FILE_ATTRIBUTE_STANDARD_SIZE, G_FILE_QUERY_INFO_NONE, NULL, &result);

 if (0 == g_file_info_get_attribute_uint64 (ginfo, G_FILE_ATTRIBUTE_STANDARD_SIZE))

 

       dv_show_error (DV_ERR_NO_FILE, parent);

       return;

(dv_show_error is a user-facing error report func) and, yes, there is a g_clear_error(&result); later.

Summary
This took me quite a bit of time and the bug in gvfsd was a significant hindrance so ensure that you test with gvfs-info before thinking there is a bug in your code. (Also remember that if you are reading files from http://incoming.debian.org/ then those files will disappear once each day when the cron job moves them into the pool.

) I recommend developing and testing against http://localhost/ during the port.
The GIO docs are relatively thin (especially for GVfs) and that is not just because GIO is still new. Starting a new application using GIO and having a working GIO/GVfs setup in place already would be much easier so new applications will work. As ever, the problems really show up when trying to port an application that has already worked around the various GnomeVFS bugs and now has to both remove those workarounds and implement one or two other changes for GIO.
Ensure your application has Depends: gvfs-backends - until the bug in gvfsd is fixed, it would be unwise to put gvfs-backends in Recommends: because that will almost inevitably result in any user without Recommends: enabled passing a call to GVfs at least once without an available backend, resulting in a broken gvfsd process and a completely broken application until the user either kills the process or logs out and logs back in. Even identifying that issue in a bug report is not straightforward - hopefully the bug report and this post will help. (Yes, depending on how you configure the ported application, it is entirely possible for this broken gvfsd process to break all file operations in your application, even local ones.) Unfortunately, there is no call (currently) to take down GVfs - you can only test to see if it is already active and that check is not sufficiently intelligent to detect the broken gvfsd process.
Subjectively, GIO does appear smoother than GnomeVFS and maybe faster. Now I need to get on and try to port other applications to GIO.....

22 March 2008

Neil Williams: GVfs and http://

Update
After contacting Sebastian Dr ge, I've found that the problem with GVfs isn't in the deb-gview code, it is a permission problem within GVfs - the current deb-gview CVS code works with remote URIs when run under sudo which isn't ideal but at least indicates the nature of the problem. Once I have confirmation and/or gvfs is fixed, I'll skip deb-gview 0.1.6 and upload 0.2.0.

** (deb-gview:31002): WARNING **: file-read:http://ftp.debian.org/debian/pool/main/g/gpe-tetris/gpe-tetris_0.6.4-1_i386.deb:The specified location is not supported

Hmm. This is with current CVS of deb-gview, already substantially modified to work with GIO and GVfs as libgnomevfs is deprecated. I wanted to look at the port because quicklist and gpe-filemanager will need similar ports.

$ dpkg -l 'gvfs*'
ii gvfs 0.2.1-1 userspace virtual filesystem - server
ii gvfs-backends 0.2.1-1 userspace virtual filesystem - backends

I have an RC bug in deb-gview that I need to fix and I wanted to do the two jobs in one but it's looking now as if I'll need two uploads, 0.1.6 with a trivial fix to unstable just to fix the existing bug and 0.2.0 to experimental with a lot more changes but partially broken functionality. It's a shame because I've got everything else working using GIO - it is only the GVfs part that is giving errors.

Anyone else using GIO and GVfs with http:// in Sid?

7 March 2008

Adam Rosi-Kessel: Aircard Dilemma

I’ve been provided the latest Verizon and Sprint EVDO cards to evaluate in the field for the past month. I now have to decide which to keep. It’s a close call (no pun intended). I’ve tested them both over various areas in Greater Boston and Washington DC. Key observations: (1) Speed: The Verizon card is usually faster. I’ve clocked up to 2.5 Mbps using the Speakeasy speed test on Verizon. That’s getting to be respectable enough to use a VPN without annoyance. My top rate on the Sprint card is about 2.0 Mbps, but usually it’s more like 1Mbps down / 0.5 Mbps up. (2) Coverage: There are more Verizon “dead” spots with no service at all. In those spots, the Sprint card invariably works fine. I’ve noticed this in some government buildings as well as on the T in Boston. (3) Device: The Verizon card I’m testing is a USB device (UM150) with an extendable antenna and the ability to power on/off right from the device. The Sprint card is one of those newfangled half-width PCMCIA cards, which requires an adapter for my laptop. There are pros and cons to each: the Verizon card is more compact when closed up and fits easily in my coat’s lapel pocket, but it seems quite precarious when actually plugged into the laptop. It could fall out easily or break if someone hit it with their bag walking by. The Sprint card, by contrast, is quite sturdy. I certainly can’t throw my laptop in my case with the Verizon card still plugged in, while the Sprint PCMCIA card can stay in without trouble. A colleague warns me, though, by keeping the PC card in I’ve created an opening for my dust and whatnot to enter the laptop. (4) Software: Finally, the (Windows) software for the Sprint card is much better than for the Verizon card. The updated Verizon software is as flaky as the last iteration. It definitely doesn’t like it if you try to disconnect after you go out of EVDO range. It also doesn’t usually survive a sleep cycle, and sometimes requires manual intervention in the task manager or a reboot to clean things up. It also has some silly features like a control panel to launch your web browser and email client. I’m not sure anyone wants to use their dial-up client that way The Sprint software has its own share of silliness by having nonstandard decoration (it looks like someone thought “skinning” it would be cool, so they took away any resemblance of regular window frame). But it’s stable and solid, survives suspend/resume, and I’ve yet to have to kill it even once. So there you have it. If anyone wants to speak in favor of one or the other, please do so in the comments. As a side note, I’m promoting broader use of the term “aircard” to make it easier to speak with nontechnical people about the difference between EVDO/WWAN and “WiFi.” Technorati Tags: Sprint, Verizon, EVDO, WWAN, Aircard

12 February 2008

Eddy Petrișor: wpa2-psk with aes on a broadcom wlan0 (2.6.24)

Update: I managed to find out why the wpa_action stuff was needed. Please ignore the lines written like ~~this~~; they are there just for reference.

One more update: it seems that the firmware needs to be in sync. I ended up using the wireless-2.6 kernel from the everything branch.

I just managed to get my wlan from my laptop to work with WPA2-PSK with AES with the free Broadcom driver (now named b43, formerly bcm43xx).


0b:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)

0b:00.0 0280: 14e4:4311 (rev 01)

In order to do this I needed linux 2.6.24-1 from unstable and the b43 driver.

bounty:/home/eddy# lsmod   grep b43
b43                   119976  0
rfkill                 12816  3 rfkill_input,b43
mac80211              132236  1 b43
led_class              10120  1 b43
input_polldev           9872  1 b43
ssb                    39428  2 b43,b44
pcmcia                 45720  2 b43,ssb
pcmcia_core            46500  2 b43,pcmcia
firmware_class         15232  2 b43,pcmcia

~~The final trick was to convince wpasupplicat to reload the config with:~~

bounty:/home/eddy# wpa_action wlan0 reload
wpa_action: reloading wpa_supplicant configuration file via HUP signal

This is the wpasupplicant.conf file that I used:

bounty:/home/eddy# cat /etc/wpa_supplicant/wpasupplicant.conf   grep -v '^\s*#'   sed 's/psk=.*/psk=aaabbb___ENCRIPTED_SEE_wpa_password___cccddd/'
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network= 
ssid="toblerone"
scan_ssid=1
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
psk=aaabbb___ENCRIPTED_SEE_wpa_password___cccddd

and this is the relevant interfaces area:

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant/wpasupplicant.conf
wpa-ap-scan 2

This is what it looks like when is working:


bounty:/home/eddy# iwconfig wlan0
wlan0     IEEE 802.11g  ESSID:"toblerone"
Mode:Managed  Frequency:2.412 GHz  Access Point: 00:1B:FC:45:33:70
Bit Rate=48 Mb/s   Tx-Power=27 dBm
Retry min limit:7   RTS thr:off   Fragment thr=2346 B
Encryption key:1337-0000-C121-d73D-0207-RE41-0000-3210 [2]
Link Quality=98/100  Signal level=-36 dBm  Noise level=-68 dBm
Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
Tx excessive retries:0  Invalid misc:0   Missed beacon:0

And here's the result of a scan (relevant section):

  Cell 02 - Address: 00:1B:FC:45:33:70
ESSID:"toblerone"
Mode:Master
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=93/100  Signal level=-42 dBm  Noise level=-68 dBm
Encryption key:on
IE: IEEE 802.11i/WPA2 Version 1
   Group Cipher : CCMP
   Pairwise Ciphers (1) : CCMP
   Authentication Suites (1) : PSK
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
         24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
         12 Mb/s; 48 Mb/s
Extra:tsf=0000000072ff542d

and here is proof it works:

bounty:/home/eddy# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.77.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0
0.0.0.0         192.168.77.254  0.0.0.0         UG    0      0        0 wlan0

bounty:/home/eddy# ping debian.org
PING debian.org (192.25.206.10) 56(84) bytes of data.
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=1 ttl=36 time=201 ms
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=2 ttl=36 time=199 ms
64 bytes from gluck.debian.org (192.25.206.10): icmp_seq=3 ttl=36 time=200 ms

--- debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 199.691/200.519/201.046/0.786 ms

Woooohooo! :-)

Thanks to all people involved in b43 development and all the ones made this possible (Debian developers).

Posted from bed, via wlan.

Update: You need the firmware blob, which can be extracted from a Windows driver with bcm43xx-fwcutter (now called b43-fwcutter); ~~I already had it from my previous attempts to configure wlan with bcm43xx. I am not sure if I should use the new tool.~~ You really need the firmware and driver to be in sync.

Update: it seems the b43 driver page (the entire linuxwireless.org site) went down sometime yesterday evening, since yesterday afternoon I was browsing through the site without any issues. (Note: I live in Europe, for reference)

25 January 2008

Neil Williams: New uploads and embedded issues in Debian

I've got an upload of gpe-tetris pending - see 462306 - to provide a smaller version of the popular falling blocks game for embedded devices. One or two things crop up from this package:

popcon - a lot of maintainers put a lot of store by popcon results but the popularity-contest package is perl and perl is not available in Emdebian (it is thrown out along with "Essential: yes" for space reasons). Writing a replacement for popcon may not be particularly sensible either because embedded devices, although often left running for long periods in a "low power" mode, often have rare and intermittent access to any form of internet connection. This could easily result in maintainers thinking that because a package has few (or even zero) popcon figures, it is not used. On the contrary, the package could simply be used on devices that either do not support perl (Emdebian) or which do not have the ability to file popcon reports despite being able to support perl. (With the probability that GPEPhone will be added to the GPE support already in Debian, users may not wish to have popcon "phoning home" because it would likely cost real money to do so - even if a C version of popcon was written.) So I'm posting this here so that I can refer back to this post if queries arise later on.

GPE apps on Debian - gpe-tetris is inherently designed for small devices with small screens and relatively slow processors, just like the majority of GPE. gpe-tetris is also designed to be usable on a handheld device where the lack of a normal keyboard can make game play awkward. As a result, playing gpe-tetris on an average Debian box is likely to appear trivially easy and the "progression" between levels would appear very slow in comparison with the tetris available in GNOME or KDE. This is deliberate and is expressly intended to allow the game to be playable on embedded hardware that has fiddly little keys. (I'll be adding this to the manpage and a brief summary of this to debian/control.) This does give the opportunity for a little sleight-of-hand such that a device could be provided with a highscore file created on a much more powerful device and so preventing any new highscores being set, but please don't do that - play nicely!

small apps != bad code - Yes, lots of GPE packages are very small, some were clearly written originally as "demos" or during the process of learning how to write larger packages. This does not necessarily mean the packages contain bad code. I will feed back sensible patches to upstream to resolve flaws in the code but please do not think ill of the packages merely because the source code looks "trivial" compared to a GNOME package.

dpkg-shlibdeps - one issue that I must begin to track after Fosdem will be to aggregate the "foo should not be linked against" messages from dpkg-shlibdeps in GPE packages and try to build a complete picture, in case there is a real possibility of completely dropping some packages that always seem to appear in that list due to the pkg-config --libs gtk+-2.0 listing. If so, I'll begin discussions with upstream about manually specifying the GTK_LIBS variable whilst retaining the PKG_CHECK_MODULES macro that ensures that the -dev package is available in the cross-building environment. This is likely to be some form of database-query mechanism - feeding data in from grepping the build logs, building a query from the list of packages to be used for a specific Emdebian root filesystem (machine/variant specific) and then spitting out whether particular package sets can have particular targets removed. If anyone fancies working on that already, the Debian version of the information is already available via the buildd network and the Emdebian cross-build results will not differ greatly from those at this stage.

Other uploads include updates of libgpeschedule, gpe-calendar and gpe-clock if gpe-announce makes it through NEW as expected. Updates for emdebian-tools and apt-cross and likely new releases for QOF, gpe-expenses and pilot-qof.
debcheckout compliance
In other developments, I've worked out how to specify Vcs-Cvs correctly such that debcheckout can find the repository data correctly. Sadly, vim syntax highlighting does not help with the CVS version but the CVS syntax is:



Vcs-Browser: http://alioth.debian.org/plugins/scmcvs/cvsweb.php/dpkg-view/?cvsroot=dpkg-view

Vcs-Cvs: :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/dpkg-view dpkg-view

Note the colon prefix to pserver and the space between the repository login location and the module name. Remember to omit the "-d" - debcheckout will add that for you (and won't check to see if you have already specified it).

23 January 2008

Ross Burton: Kernel Patching

In my recent PowerTOP adventures I discovered a few timers which could be removed. One was a polling loop in the PCMCIA driver, which I disabled because the interrupts are unreliable, apparently. This turns out to be totally correct, with the polling disabled it doesn't notice me inserting a CF, so I can't do anything. I'll leave this on the "something to pester Richard about when he is less busy" list. The next driver related poll on the list was from a IrDA module. Now, it shouldn't be doing anything because I have nothing apart from the drivers loaded. Even unloading the real drivers and just loading irda.ko caused wakeups, so I hunted around and with lots of Samuel's help (he took my concept patch, and made it actually compile!) we produced a patch which was merged into David Miller's 2.6.25 tree today. Excellent, I'm now a kernel hacker!

13 October 2007

Julien Valroff: ndiswrapper and WPA

I had been using ndiswrapper with a Netgear WG511 PCMCIA card^[1] without any problems for a while, then have begun to get kernel crashes, which were more and more frequent. I have thus backported to Etch the 1.47 version available in Sid, which *does* fix my kernel crashes. However, this newer version has brought new problems: with a “high” network load, the module just crashes silently, and has to be reloaded so that the network connection can be enabled again. I have packaged ndiswrapper 1.48 as the release notes let me think my issues were fixed (”Disassocation with wpa_supplicant is fixed”), but the problem is still there with this latest release! I have finally managed to get things work correctly thanks to this post: I use Debian linux-image, ie. without preemption enabled, and I can now confirm the still-to-be-released 1.49 version fixes this issue. I have uploaded 1.49-rc3 packages to my unofficial repository just in case someone has the same issue.

Linknotes:

the free prism54 unfortunately does not support WPA ↩

13 September 2007

Neil Williams: apt-cross moves to Cache::Apt:: and GPL-3 or later

Just completed the migration of the next version of apt-cross that is due to be uploaded once dpkg-cross pre2 can be uploaded to experimental. (This in turn is waiting for dpkg to support removal of the dpkg-cross diversions: #439979.)
AptCross:: has gone, replaced by Cache::Apt:: and the Cache.pm from NorthernCross is now called Lookup.pm for clarity.
This update solves a lot of niggles with the old apt-cross behaviour when dealing with non-standard repositories, CDROM archives, proxied mirrors and various other stuff that apt can cope with but which wget found difficult. (#440929, #442012)
Also, the entire package has migrated to GPL v3 or later - all the code was GPL v2 or later.
This means that emdebian-tools will also be migrating to GPL v3 or later when that is updated to use the new apt-cross and dpkg-cross code.
Sometime after Lenny, Cache::Apt:: will migrate into a source package of its own (on CPAN), allowing the apt-cross functionality to be merged into apt and the module to support other tasks in Emdebian.
In other news, gpe-cash is coming along and highlighting a few issues in libqof1, libqof-backend-sqlite and libqofexpensesobjects so there are improvements due there too. gpe-cash and gpe-expenses are also GPL v3 or later, as are deb-gview, quicklist (experimental) and pilot-qof now too.
Most have some machine-operable fields in debian/copyright and most have the new dpkg fields in debian/control.
Got a fix for gpe-bluetooth to upload tonight as well as (hopefully) the last go at getting homebank through NEW.

19 August 2007

Adam Rosi-Kessel: Solid State Kitchen Linux Box

Dear LazyWeb: Our kitchen laptop is on its last legs. I’d like to replace it with a standalone LCD and a cheap, quiet, low-power CPU with just one or two gigabytes of storage for the operating system (music and other data are stored on a server in the basement). Can someone point me in the right direction? This is an instance where Google doesn’t provide an obvious leading/consensus solution. Most searches for solid state computers point to laptops, which isn’t what I want. The closest thing I’ve found is the Zonbox, but I’m not interested in their network/subscription storage model. Ideal specs:

Total cost less than $300 (preferably less than $200)
High-end Pentium III or lower-end Pentium IV, or equivalent. Should be able to play ogg files and browse today’s overactive websites at the same time without user latency. No need to support graphics-intensive applications like gaming or video editing.
Built-in wireless networking. Support for a PCMCIA wireless card would also be acceptable. Most data will be accessed via an NFS share on the WAN.
1GB or 2GB of Flash memory for storage.
Standard VGA out, preferably at least 1280×1024 (although 1024×768 would be okay).
USB ports for keyboard, mouse, possibly external hard drive storage when needed.
Painless Debian/Ubuntu installation, including out-of-the-box suspend/resume functionality.

Suggestions?

Joerg Jaspert: UMTS?

Im currently looking if a UMTS data connection (flatrate) is something for me. Looking around it seems Vodafone has the best network for UMTS with that HSDPA technology (3.6MBit/s max. instead of only 384kbit/s). Especially the area I am most interested in - my way to work, is only available with HSDPA from Vodafone, all other telcos dont seem to be able to get UMTS there. Some days ago I sat besides someone in a train back home who was using UMTS connection. And didnt seem to have any problems. When I asked he told me that its fairly stable, on the whole way he only knows two points where the card seems to switch to the slower GPRS way. And looking at his screen he was using some weird webchat thingie, so nothing that likes too huge lags. (Ah, btw - how can anyone seriously chat in such a weird way? I mean - we have IRC, WTF are people dumb enough to use their webbrowser to chat? Thats so silly) My main usage would be to be online on the way to work / back home, which is about 1.5h each, so 3hours on days where I go to work (using ICEs, so at least there are repeaters for the mobile stuff in the trains). Most of my online usage is ssh based, usually via (Open)VPNs, then some mail sync runs and various small things. Moobicent does offer a flatrate (a real one, not such a “customers are dumb and dont see it is trafficlimited just because we named it flat”one) using the Vodafone network. The hardware I need for it costs 99EUR when I order there. Its some PC Express Card that comes with a PCMCIA Adapter. Now, has anyone out there reading this blog experiences to share? Using google there is Marcs blog which suggests it shouldn’t be too hard to get it all running, but maybe there is something I missed to take into account? Comments? Suggestions? Anything? Email me or catch me on IRC, (no, my blog doesnt have comments), and I summarize the results later. Update:UMTS == 3G; 2 People already told me that the Vodafone net is the right selection in Germany, one said the same for UK.

18 August 2007

Joerg Jaspert: UMTS?

13 August 2007

Uwe Hermann: Linux on the Fujitsu Siemens Lifebook S-4572 Subnotebook

I recently bought a Fujitsu-Siemens LIFEBOOK S-4572 (sub)notebook on eBay for less than 150 Euros, a really great little machine. It's a Pentium III, 750 MHz, 256 MB RAM (the chipset cannot handle more than that unfortunately), 12.1" screen, ethernet, 2x USB 1.1, CD-ROM/DVD reader + CD-ROM writer, PCMCIA, IrDA, modem, and a 15 GB hard drive. No floppy, no serial ports, no parallel port. There's no wireless builtin, but I use a cheapo PCMCIA adapter. The greatest feature compared to all other laptops I previously owned is that the battery life is really great, it lasts almost 3 hours (compare that to 45 minutes on my current "main" laptop). I'm running Debian unstable on the box (of course). Here's the Linux support status as far as I have tested things: Networking Works out of the box using the e100 driver. Sound Works out of the box using the snd_intel8x0 driver. X11 Works out of the box, using either the vesa or the ati driver (at a max. resolution of 1024x768). Touchpad Works out of the box. Using the Option "SHMConfig" "on" line in /etc/X11/xorg.conf's InputDevice section (using the synaptics driver) also works fine and allows you to scroll using the touchpad, e.g. in a browser. More info in the SynapticsTouchpad page on the Debian wiki. CDROM, DVD Reading CD-ROMs and DVDs as well as burning CD-ROMs works fine. I don't think the drive is capable of writing DVDs. External VGA Displaying the screen contents on an external VGA monitor (or beamer) works just fine, switching is done using Fn+F10. PCMCIA Works fine, tested using the Sitecom WL-112 wireless card. The driver installation for that is straight-forward, too:

$ apt-get install rt2500-source
$ m-a a-i rt2500-source
$ dpkg -i /usr/src/rt2500*deb

Special keys All the Fn-keys work fine (brightness, volume, etc.). There are five other special keys (for starting a browser or something) which I haven't tested, but I don't really care... USB Works fine, but it's only USB 1.1, so some higher-speed devices will not work (DVB-T USB devices for example; PCMCIA DVB-T adapters might work). IrDA, Modem Untested, I don't care. Powersaving, Suspend to RAM It seems this CPU (Pentium III, Coppermine) doesn't support frequency scaling, so cpufreq-set doesn't work. I'm using laptop-mode-tools to improve battery life a bit more, though. Also, Suspend-to-RAM works fine out of the box:

$ apt-get install hibernate
$ hibernate-ram

I haven't tested Suspend-to-Disk yet, but I'm not sure it'll work anyway, as I'm using a dm-crypt'ed disk (+ LVM), as with all my boxes. lspci

00:00.0 Host bridge [0600]: Intel Corporation 82440MX Host Bridge [8086:7194] (rev 01)
00:00.1 Multimedia audio controller [0401]: Intel Corporation 82440MX AC'97 Audio Controller [8086:7195]
00:00.2 Modem [0703]: Intel Corporation 82440MX AC'97 Modem Controller [8086:7196]
00:07.0 Bridge [0680]: Intel Corporation 82440MX ISA Bridge [8086:7198] (rev 01)
00:07.1 IDE interface [0101]: Intel Corporation 82440MX EIDE Controller [8086:7199]
00:07.2 USB Controller [0c03]: Intel Corporation 82440MX USB Universal Host Controller [8086:719a]
00:07.3 Bridge [0680]: Intel Corporation 82440MX Power Management Controller [8086:719b]
00:12.0 Ethernet controller [0200]: Intel Corporation 82557/8/9 [Ethernet Pro 100] [8086:1229] (rev 09)
00:13.0 CardBus bridge [0607]: O2 Micro, Inc. OZ6933/711E1 CardBus/SmartCardBus Controller [1217:6933] (rev 02)
00:13.1 CardBus bridge [0607]: O2 Micro, Inc. OZ6933/711E1 CardBus/SmartCardBus Controller [1217:6933] (rev 02)
00:14.0 VGA compatible controller [0300]: ATI Technologies Inc Rage Mobility P/M [1002:4c52] (rev 64)
01:00.0 Network controller [0280]: RaLink RT2500 802.11g Cardbus/mini-PCI [1814:0201] (rev 01)

Other resources

I'm really considering making this my "main" box even though it's a bit older/slower, as my current laptop with 45 minutes battery life is a major pain when travelling...

5 June 2007

MJ Ray: Cooking MPs

Seen on uk.rec.cycling: "I'm sure MPs can be cooked in ways that make them edible. Perhaps the best way is to boil them in calvados for a few hours and then serve with an apple sauce and vegetables of the season. The bones can no doubt be boiled up for stock and the remains deposited in one's green cone." David Hansen PS: I'm back from France. Did you miss me?

22 March 2007

Fabio M. Di Nitto: PUMP UP THE VOLUME!

Two of these toys just landed on my laps:

QLogic Fibre Channel HBA Driver
qla2xxx 0000:03:04.0: Found an ISP2422, irq 69, iobase 0xf6000000
qla2xxx 0000:03:04.0: Configuring PCI space...
qla2xxx 0000:03:04.0: Configure NVRAM parameters...
qla2xxx 0000:03:04.0: Verifying loaded RISC code...
qla2xxx 0000:03:04.0: Allocated (1061 KB) for firmware dump...
qla2xxx 0000:03:04.0: Waiting for LIP to complete...
qla2xxx 0000:03:04.0: Cable is unplugged...
scsi3 : qla2xxx
qla2xxx 0000:03:04.0:
QLogic Fibre Channel HBA Driver: 8.01.03-k
QLogic QLA2460 - PCI-X 2.0 to 4Gb FC, Single Channel
ISP2422: PCI (66 MHz) @ 0000:03:04.0 hdma-, host#=3, fw=4.00.27 [IP]

more FC-HBA! more fun! My Niagara T2000 has now 4 (3 PCI-E + 1 PCI-X) FC-HBA controllers topping what my ancient SAN can really do considering the age and the few parts branded Digital, but best of all is the above dmesg coming from a J5000 pa-risc machine. The Qlogic controller was the first one to actually pass the POST (opposite to the Emulex that hangs everything hard). One cluster, 5 different architectures, 7 machines. This project is becoming interesting to stress portability of things like OCFS2 or GFS2 and their user land tools. Sometimes i wish to have a few pcmcia -> FC-HBA to plug a ppc laptop and an amiga 1200 m86k :)

25 November 2006

Joachim Breitner: USBless in Africa

(For those who just turned in: I m currently in Ghana, doing some Free Software advocating. Read the rest of the blog for more)I just came home from a nice day trip to Ada (see my next German post on that), wanting to load my pictures on my laptop. My laptop was already running, as I m mirroring the debian archive to my external hard drive, as I need that for my work at the Kofi Annan Center in Accra. So I plugged in my camera to the second USB port and copied the files onto my laptop. Fine so far.I happen to have a second hard drive with, among other things, has a copy of my picture website. I then generate and update the thumbnails and web pages there, before I upload the changes with rsync. But when I plugged in the cable (I don t think I plugged the hard drive in already), my laptop, an IBM ThinkPad 41p, suddenly goes off. It took a few seconds and the removal of the battery to turn it back on again.Now it seem that my USB is broken. The system logs says it detects the internal hub all right, but shows no reaction to any devices (hard drive, camera, mouse) that I plug in. The disks get power and spin up, the optical mouse stays dark. Same thing if I use the port replicator. The internal Bluetooth device powers on (according to the LED) but is not detected as well by the sytem. So looks like my laptop now has no USB support any more.This is a bummer. I m in the middle of the so called forgotten continent, and I need my laptop with out it as a tool, I could not do my work at KACE, and I could just fly home so sending it in is not an option. On the other hand, I also somewhat need the USB port: I can t publish my pictures without it, I can t do backups and I can t have the debian mirror that I need for my DeCaf project that I want to work on at KACE. I only have two hopes: That it will work after the next reboot or that I can find a reasonably priced PCMCIA-USB2-Adaptor in Accra. Wish me luck.

Next.

Previous.